CONFIG.SYS and AUTOEXEC.BAT -------------------------------------------------------------------------------- Introduction During the startup of an IBM or compatible computer, the operating system looks for two files of user supplied commands which allow you to customize your system in various ways. This Web page will attempt to explain some of the options available to you when you make these basic files. While I have written it for the relative novice, I hope it may provide some useful new tricks even to the more experienced user. These two files whose names must be CONFIG.SYS and AUTOEXEC.BAT should reside in the root directory of your boot diskette or of your hard disk if you boot from a hard disk (i.e. if you can start your system from your hard disk without placing a diskette in drive A). Actually, there is a method for placing the AUTOEXEC.BAT file in a subdirectory but despite the fact that I tend to be fanatical about keeping the root directory lean, I don't recommend using this option. When you turn on your computer, the computer is setup to begin a program in the ROM (read only memory) that all IBM compatible machines have. This ROM is distinct from and in addition to the working RAM (random access memory). When you are sold a machine with 1MB or more of memory, that figure refers to the RAM. There is an additional 32K-256K of ROM. RAM is cleared whenever you turn off your machine or reboot while the ROM is more permanent and should not change. Boot Up The program that is automatically run from ROM begins with a brief test of various components of your computer. If you have a 386, 486, or Pentium, the most noticeable part is the memory (RAM) test accompanied by counting up the memory on your screen as the test progresses. This test is skipped when you do a warm reboot by hitting Ctrl-Alt-Del. You may also notice your drives and printer "burping" as they get tested. After this test, the machine searches for various "ROM extensions" that is additional ROM that can come with a hard disk or VGA card for example. The program then searches first drive A and then a hard disk if you have a bootable hard disk for a diskette or disk program to transfer control to. It transfers control to the very first sector on the disk which is called the boot sector. When you format a diskette, a little program is placed in the boot sector which will display the message "non system disk, replace and hit any key". When you transfer the operating system to the disk with the SYS command or via FORMAT/S, this boot sector program is changed to transfer control to a program which must be in the position immediately following the boot sector. If the disk has the system on it, control is transferred successively to two hidden files which load the BIOS ("basic input/output system" part of which is in ROM) and the DOS ("Disk operating system"). When most users think of DOS they think of the familiar DOS prompt C: and some of the DOS commands like DIR and COPY. These parts of the DOS are only loaded later; the part in the hidden file involves services provided by DOS to programmers rather than directly to users. The two hidden files are called "IO.SYS" and "MSDOS.COM" in Microsoft DOS and may have different names with other versions of DOS like DR DOS and PC DOS. Parenthetically, I want to note that there isn't really much hidden about hidden files. As you may know, the DIRectory you are used to display gets its information from a special file also called the directory. This file is essentially a little database with information about each file including the filename, extension, date and time of creation. One byte in the record for each file is called the attribute byte and contains eight "switches" to keep track of things like whether the file is a volume label, read only, etc. One of these switches is whether the file is "hidden". To anyone with any programming experience or with any of a large number of public domain or commercial programs, these files are not in any sense hidden. The basic DOS services like DIR and COPY are specially set up to ignore hidden files and that is the only sense in which these files are hidden. The two system files are hidden and read-only because their location is critical for a successful boot-up and they are less likely to be moved by accident if they marked as hidden and read-only. After the second hidden file is mainly loaded, it looks for a special file called "CONFIG.SYS" and processes the commands in it. Then control is passed to the third file in the operating system, COMMAND.COM. As the final step in booting up, COMMAND.COM looks for a file named AUTOEXEC.BAT and if found it loads it and runs it. If not found, COMMAND.COM exits with the DATE and TIME commands. Except for its special status as a boot up file, the AUTOEXEC.BAT file is an ordinary BATch file with the usual rules of syntax. The CONFIG.SYS file has a special syntax with a limited number of allowed commands. Both must be pure ASCII files, that is without any special formatting codes that some word processors add. Many word processors which have special codes have a "non-document" mode for preparing ASCII files. These files have separate lines which must be ended with carriage return/line feed pairs. If you have any doubts about whether the file is "pure ASCII" you can use the TYPE command to display it on the screen and see if it just has ordinary letters and numbers. What Goes In The Root Directory When a subdirectory fills up, it adds another cluster of disk space to increase its size but the size of the root directory is fixed at the time the diskette or disk is formatted. It is not merely because of the size restriction that I recommend that you keep your root directory slight. Since the files in the root are likely to be of diverse type, it will be difficult to keep track of things if you put too much there. I mainly put subdirectories there and mainly subdirectories which have no files but only subdirectories. For example, I have a WP subdirectory with my word processor, spell checker, thesaurus, etc in subdirectories. Generally, there are only three files that I recommend go into the root: COMMAND.COM, CONFIG.SYS and AUTOEXEC.BAT. As I mentioned, one can put AUTOEXEC.BAT elsewhere and even COMMAND.COM but I feel that is carrying things too far. In fact, I even have a LOCAL.BAT file of the type I'll describe there but the point is to keep that directory thin and to complain bitterly about software so inconsiderate that it forces you to place it in the root directory. My point in mentioning this here is that I'm about to discuss device drivers which many people put in the root directory. If you like to be organized, I recommend you put the drivers in specific directories with related files so, for example, the DOS drivers HIMEM.SYS and EMM386.EXE are in the C:\DOS directory, and the network drivers are in the directory C:\NWCLIENT. Device drivers There are a group of programs which are made permanently resident and which are loaded as part of the CONFIG.SYS. Virtually any resident program can be produced in this format but certain ones must be of this form. Typically, console drivers and any program which controls "a device" must be loaded now. The programs that make access to CD-ROM drives and sound cards possible are loaded as device drivers. While device drivers are programs, they need not have the extension "COM" or "EXE". In fact, so far as I can tell their extension can be anything the developer wants. Nevertheless virtually all commercially available device drivers have an extension of SYS, COM, or EXE. Some drivers are available with the extension DEV. The syntax for loading a device driver in your CONFIG.SYS is: device= So if you have a device HIMEM.SYS in the directory C:\DOS and it will take a numeric parameter to set the size of some buffer, you might load it with: device=C:\dos\himem.sys 128 Note that it is essential to include the extension SYS or else you will get an error message "bad or missing HIMEM". The drive letter C: is not required but it can't hurt and I know of one person who claimed the device driver on her machine couldn't be found without it. The question of which parameters a given device driver allows or whether it allows any at all depends on the driver and should be dealt with in the documentation for the program in question. For the drivers ANSI.SYS and VDISK.SYS which come with DOS, I note that the former takes no parameters while the later takes parameters explained in the DOS manual. DOS 6.22 comes with a third driver called DRIVER.SYS while some versions of MSDOS 6.22 comes with an alternate ram disk called RAMDRIVE.SYS. Both take parameters. Examples of Device Drivers: the default drivers I will not attempt to describe all available device drivers since there are so many. A device is a virtual file which can typically be written to and read from. The most common example is "con" which you typically read from when you issue the command "copy con filename". Devices can only be installed via the CONFIG.SYS. Despite the name, the device command can load other programs which do not control devices and physical "devices" may not be devices in the sense of setting up a virtual file. A mouse is a good example of something which is not a device in this technical sense. The hidden file MSDOS.SYS sets up several devices even if you have no CONFIG.SYS: con, prn, aux, lpt1, lpt2, lpt3, com1, com2. Con, short for console is a combined keyboard/monitor device, prn for printer is by default a name for lpt1 and aux a name for com1. The DOS mode command allows reassignment of these devices. LPTn and COMn are names for the parallel and serial ports on the computer. These device names are assigned even if you don't have the full complement of ports. The Novell command CAPTURE can also redirect the lpt ports to a network printer. CONFIG.SYS Commands The FILES command DOS is a prisoner of its past. Original IBM PC's came with only 16K of memory (!) so when DOS boots up it sets aside memory for various purposes in an incredibly frugal manner. The defaults for three regions of memory set aside for file handles, disk buffers and environment are woefully inadequate. If you know what you are doing, it is easy to change these defaults but it's unfortunate that the novice gets stuck with these small values. In any event, FILES and BUFFER commands are among the most important for you to include in your CONFIG.SYS. When DOS opens a file, it keeps certain information in memory to be able to quickly access the file. This information is called a file handle. During boot up, memory is put aside for these file handles so a limit is placed on the number of files that can be open at one time. The default is eight which may seem adequate since programs normally close files when they are done allowing the file handles to be reused. However, eight is often not adequate. DOS uses four of the handles itself for "files" like con and prn. Thus there are four available for your programs. Some resident programs leave files open and even the ones that don't, may need to open a file for an initial access at the same time that an application program have several files open. Database programs often have separate index and data files and typically may want to have more than four open files. If DOS is asked to open a file and a handle is not available, DOS issues an error message and the running program may even abort. I strongly recommend that you place the line: FILES=40 in your CONFIG.SYS file. If you are running Microsoft Windows then set the files=80. The cost in conventional memory is about 40 bytes per handle. For most purposes 40 should suffice. BUFFERS You may have heard of disk caching. As you've noticed, diskette access is very slow and even a hard disk has access times much slower than RAM access times. Disk caching sets aside some RAM to keep a copy of the most recently accessed disk information so, for example, if a database is continually accessing a disk, the first time the disk is really read but the next time the copy in cache memory will be read instead. This is not the place to discuss the pros and cons of commercial disk caching software but you should know that DOS comes with some free rudimentary disk caching included. It keeps N buffers of 512 bytes each with the copies of the last N disk sectors accessed. By default N is only eight on most DOS systems. You should certainly make this number larger by including the line: BUFFERS=N in your CONFIG.SYS where recommended values of N are between 10 and 25. Let me tell you an anecdote to show how dramatic a difference this number can make. The first time that I ran my tape backup drive to backup my 30 meg hard disk, I was bitterly disappointed. Despite what I'd been told by the salesman, it took over 45 minutes! The next day, when I thought about it and tried again, it took only 8 minutes! What had happened? The first time I had been nervous about the effect my many resident programs might have so I put an original write protected DOS disk in drive A and rebooted before running the backup software. This disk had no CONFIG.SYS so I was running with the default three buffers. The next day, I used my regular hard disk boot with buffers=20 and that made the difference. I have done some time tests comparing something as simple as copying a directory from a hard disk to a floppy and I've found that using extra buffers can decrease times by 30 or 40 percent. So USE YOUR FREE DISK CACHING. Note: If you are using SMARTDRV.EXE then set your BUFFERS=10. SMARTDRV is more efficient and can use extended memory. This will leave more conventional memory for your programs to run in. The issue of precisely how many buffers to take is not an easy one. Increasing the number of files handles has little effect on memory or efficiency so you can freely take files=99 if the mood strikes you. This is not so with buffers. Each buffer takes .5K of RAM so buffers add up. Moreover at some point it will take DOS longer to check through all its buffers looking to see if a file is there than it would take it to access it directly. I've seen the number 25 given as a dividing line but I would like to do some tests to check this out. I can only say that I've settled on buffers=20 myself and that with a floppy based system, you should take a higher figure than you might with a hard disk. Increasing your environment DOS sets up a special section of memory called the environment which has a default size of 160 bytes. This area must hold your path, your prompt, the place that COMMAND.COM can be found and various other strings. Programs can communicate with you by asking you to place information in the environment with the SET command. In addition you can keep global variables in the environment to pass between BATch files. If you attempt to place more there than it has room for you'll get a message "Out of environment space". With DOS 3.1 and later there is a CONFIG.SYS command allowing you to increase the amount of space reserved for your environment. The syntax is: shell=C:\command.com /P /E:nnn where n is the number of bytes you want to set aside for the environment. For DOS 6.22 nnn represents the number of bytes you want to set aside. So for a 2K environment take nnn=2048. How much space do you need for your environment? That depends on your path, applications and how fancy a prompt you make. For our network you should set aside at least 2K. For more advanced users, I note that the environment is not as benign as you might think. I know of several programs which crashed if there was too much in the environment (most of the ones I know about have been fixed) and one that crashed if the PATH was the last thing set in the environment. I have occasionally been baffled at what could be causing a conflict only to discover the culprit was the environment. Miscellaneous CONFIG.SYS commands There are some other commands that can go in your CONFIG.SYS: You can turn BREAK ON that is have the operating system check for control C more often than just during disk I/O. This slows down certain processing but gives you more safety from certain kinds of dead ends. The syntax is a line saying: BREAK=ON Unlike any other CONFIG.SYS command, this one can also be issued from the DOS command line or in your AUTOEXEC.BAT file. In addition to file handles, DOS has something call file control blocks which in DOS 6.21 can be changed by an FCBS command. These are needed only if you have a LAN (local area network) and the parameters to take should be discussed by your LAN software. On our network the default value is acceptable. DOS 6.22 has a STACK command. From what I've read this is a real kludge and the manual seems to suggest that it was added in DOS 3.1 at the last minute to solve a problem connected with a new way that DOS 3.2 treated the stack. In any event, if you use DOS 6.22 and seem to have unexplained crashes, try adding STACK=16,512 to your CONFIG.SYS. One final remark about your CONFIG.SYS. The order of the commands is irrelevant except to the extent that certain device drivers like to be loaded before others. As with most DOS commands the syntax is not case sensitive. As a review of what a CONFIG.SYS can contain, let me list the CONFIG.SYS from one of our machines which is running DOS 6.22: DEVICE=C:\DOS\HIMEM.SYS DEVICE=C:\DOS\EMM386.EXE RAM REM DEVICE=C:\DOS\EMM386.EXE NOEMS DOS=UMB DOS=HIGH BUFFERS=10,0 FILES=80 LASTDRIVE=Z FCBS=16,0 STACKS=16,512 SHELL=C:\COMMAND.COM /E:2048 /p BREAK=OFF What should your AUTOEXEC.BAT contain? Most of my AUTOEXEC.BAT file loads my own particular blend of resident programs. This is not the place for me to advise you on what resident programs you might want to put into your system but I would like to make some comments about DOS and general aspects of what goes into your AUTOEXEC.BAT file. First, if you have very many resident programs, they may have conflicts and you must be prepared to permute the order of loading which often cures some or all of the conflicts. In addition to loading a stable of resident programs your AUTOEXEC.BAT can contain some of the following: VERIFY ON command. This slows down copying because DOS checks that the copy at least has consistent CRCs; this is not the same as comparing after copying but it is a fairly good check. Only several compensating errors could pass this test after an incorrect copy. PROMPT. At a minimum use prompt=$p$g This will display the famiular C:\>. PATH. If possible, keep your path short since every time you type in a bad command, DOS will have to read every directory in the path before responding "Bad command or filename". Also try to list the path in the order of how many times you expect to access a given directory. That is place the directories you call most often early in your path. Summary This short summary of the CONFIG.SYS and AUTOEXEC.BAT has only touched on a few of the many commands that are available to you. For more complete information use the DOS help system that has been installed on each of your systems. At the DOS prompt enter: C:\DOS\HELP CONFIG.SYS or C:\DOS\HELP AUTOEXEC.BAT By using your CONFIG.SYS and AUTOEXEC.BAT files you can personalize many aspects of your PC. --------------------------------------------------------------------------------